【レポート】担当者だったら心をかなり強く持つ必要がある…世界最大規模のECサイト移行ミッション！Amazon.com におけるデータベース移行事例 #AWSSummit

AWS Summit Online Japan 2020

#レポート

#AWS

豊崎隆

2020.09.09

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ご機嫌いかがでしょうか、豊崎です。2020年9月8日から30日まで開催されるAWS Summit Onlineを自宅から拝聴しています。

本記事で取りあげるセッションは、「Amazon.com におけるデータベース移行事例」です。

セッション情報

スピーカー

アマゾンウェブサービスジャパン株式会社技術統括本部ソリューションアーキテクト北澤英崇

概要

Amazon.com では、オンプレミスで稼働していたシステムを AWS へ移行しました。この移行では、これまで利用していた商用データベースから Aurora with PostgreSQL Compatibility などの AWS データベースへの移行を実施しています。本セッションでは、このデータベース移行をどのように実現したか、移行プロジェクトを推進するにあたって実際に行ったチャレンジ、データベース戦略についてお話ししたいと思います。

レポート

Amazon.comのレガシーデータベース基盤

当初(1995年)のAmazon.comは以下のようなUIサイトでした。

見た目はシンプルですが、バックエンドのアーキテクチャは当時最も革新的なシステムの一つだった
- WEBアプリケーションサーバからの注文
- 注文データをOracleDBに格納
- 商品が発送後、トランザクション完了前に銀行とお客様のクレジットカード会社の支払い処理を実行

しかしビジネスが大きくなり、より多くの注文が発生すると様々な様々な問題が発生する
- 中心となるDBがダウンしたら
  - オンライン注文に影響が出るだけではない
  - 注文済み商品の発送や支払い処理も停止していた
モノリシックから複数のへ分割
- 注文サービスやクレジットカード決済サービスなどサービスごとに分割したアーキテクチャへ
- 各サービスごとに拡張が可能
- SOAの考えを実装

しかしRDBのスケーラビリティ部分に課題は残った
- キャパシティオーバーに対しては垂直なスケールで対策
- スケールアップにはダウンタイムが発生する
- また垂直スケールにはハードウェア限界がある

スケールアウトによる負荷分散を検討
- データベースシャーディングで対応
- データベースはキャパシティオーバーになるとデータを分割配置することで分散をはかる
- どのデータがどのデータベースに格納されているかはシャードトラッカーで管理
- データはシャードキーによって格納されるデータベースが決まります。
- アプリはシャードトラッカーで処理したいデータがどのデータベースにあるか判断して適切なデータベースに接続する
- データモデルや基盤となるデータベースアーキテクチャを変更することなくシステム全体の処理量が増加

Amazonのビジネスがさらに拡大
- データベース及びデータ量が膨大に
- 2017年時点で
  - データベース数：7000
  - 総データ量：70PB
  - 世界中で数百万の受発注、決済、処理
  - 分析対象データ
    - データ量：50PB
    - テーブル数：75000

データベースを移行した理由

決断に至った課題
- スケーリングの問題
  - プライムデーなどの大規模イベントの拡張作業に60週間もかかるチームがあった
  - ベンダーからのサポートを受けていてもスケール時の障害リスクが高かった
  - 夏のプライムデー、冬のブラックフライデー&サイバーマンデーで年２回のピークが発生
    - スケーラビリティは重要な課題に
- レイテンシー問題
  - Amazon,comにとってレイテンシーの改善は非常に重要なファクター
  - データ量、ユーザ数が増えていく中で改善をするためには2-4倍の改善が必要だった
  - データは70PBかつ指数関数的に成長
    - 運用管理のコストが膨大
- ハードウェア、ソフトウェアに関する問題
  - システム規模が大きくなるにつれてコストが過剰にかかっていた
  - ハードウェアについては納品設置までのタイムラグ
    - 納品タイミングとビジネス的に必要な時期を合わせることが困難
  - ソフトウェアについてはベンダー側のライセンス変更によってコストが上がってしまう
- 拡張性、可用性と運用のリスク
  - スケールアップとスケールダウンの両方が必要だった
    - ピークイベントに伴う必要キャパシティの山がくる
    - それ以外についてはスケールダウンを求められた
  - データに関する一貫性
    - Amazon.comの規模では非常に難しい問題
これらの問題によってAmazon.comはクラウドを決断する

移行戦略と学んだ教訓

Amazon.comはOracleを停止して約7500のデータベースの移行が完了したことを2019/10に発表
移行元のOracleはRDBだが移行先は目的別に作られたデータベースをコンセプトとした
- 適材適所のデータベースを利用する
- より高いパフォーマンス、可用性が求められる場合はDynamoDB
- DWH用途の場合は、Redshift
- RDBを使う場合でもAmazon AuroraやAmazon RDS

データベースの移行

AWS Database Migration Serviceや、AWS Schema Conversion Toolを活用
AWS DMSはデータベースのデータを移行するためのサービス
- OracleからPostgreSQLなど異なるデータベースエンジン間での移行が可能
AWS SCTは異なるデータベース間でのテーブル定義、スキーマ、ストアドプロシージャを変換

具体的な移行戦略

#1:可視性の向上

データベースの全体像が把握できていなかった
- データベースのメタデータを取得し、接続ログを分析し関連性を可視化
- また新たなデータベースや移行完了したデータベースの情報も付与
- それにより移行のオーナーの明確化、影響範囲、移行進捗状況が可視化された
テーブルの使用状況やスキーマに関する詳細情報が必要となった
- CRUD（Create/Read/Update/Delete）の情報収集を開始
- マテリアライズドビューによる相関が追跡可能に
アプリケーションが利用しているテーブルの可視化
- Java ClassのWrapperを作成してAppが実行するSQLを分析
- AppのSQLレベルで収集分析することで可視化が可能に
可視化によって綿密な移行計画の実行が可能になった

#2:経営陣からのサポートを加速

当初経営陣が移行計画の状況を把握できていなかった
- 複数のダッシュボードを作成
- データベース移行の進捗を可視化したグラフ
- 進捗を把握し説明責任を果たすためのレポート体制

#3:社内のOracleDBAからの支援を得る

当初OracleDBAからの反発があった
- 反発の原因は移行に対する疑念や恐れ
- 実際の技術的課題とは違った
- FUD：Fear Uncertainly Doubt（恐れ、不確実性、疑念）
移行によるメリットを考える
OracleDBAへのキャリアパスとトレーニング機会を提供
- DB移行スペシャリスト
- データベースエンジニア
- システム開発エンジニア
- ソリューションアーキテクト
- AWS認定資格者
- などなど

#4:移行エンジニアの増強

各チームのDB移行のプロフェッショナルを作ろうと考えていた
- 当初、プロフェッショナルの育成がうまくいかなかった
- 情報のシェアをすることで育成が加速
  - 定期的な勉強会
  - リファレンスアーキテクチャ
  - ベストプラクティス
  - デザインパターン
  - Tipsのシェア
  - など